Does it make sense to add new specials? They make devs lives easier but a lot of them are also subjective meaning why would you add X but not Y?

Does it make sense to add new specials? They make devs lives easier but a lot of them are also subjective meaning why would you add X but not Y?

When script cmds take arguments I personally always prefer a callnative. With specials you have to use scripting vars for Args which has the (rare) potential to stomp on other values you've set previously in the script.

Does it make sense to add new specials? They make devs lives easier but a lot of them are also subjective meaning why would you add X but not Y?

When script cmds take arguments I personally always prefer a callnative. With specials you have to use scripting vars for Args which has the (rare) potential to stomp on other values you've set previously in the script.

The same question applies. Would it make sense to add them? Just trying to figure out scope on this one

Does it make sense to add new specials? They make devs lives easier but a lot of them are also subjective meaning why would you add X but not Y?

Is there a good reason not to add as many as we want? There's no scrolling list or menu with finite space. Space isn't an issue, we can switch to callnative if the special table is finite.

I was inspired to add this once 4189 was merged. If we can add things that would improve quality of life, we should.

When script cmds take arguments I personally always prefer a callnative. With specials you have to use scripting vars for Args which has the (rare) potential to stomp on other values you've set previously in the script.

ghoul two of these are yours and they're not callnative
If wrapping all of these in functions that use scriptcontext and callnative is blocking, I think that's fair and I'm happy to do it.

I was inspired to add this once #4189 (review). If we can add things that would improve quality of life, we should.

I'm generally wondering what is going to be useful for other projects because I would guess most of the time people write their own specific specials that only make sense for their projects. So trying to avoid the trap where we accept each random special basically answering the question why X but not Y.

I edited my post but I don't think you saw it in time. In any case, I think we all agree that a command for a specific scenario in one person's game should not be merged.

If you're looking for a guiding principle, I trust the (current) Senate enough to say:

If another Senate member thinks "yeah, this could be generically useful"

then it should be merged.

it is mere coincidence that these were all written by current Senate members and therefore passes that bar

I personally think setmonball doesn't qualify since it's a non-vanilla feature, I'm fine with the others. For removeallitem it may be useful to return (through VAR_RESULT) the amount of removed items for an easy addition of further logic. I also don't think the checkspecies variants need to exist; rather, one of the two could be set as the default with the other needing to be explicitly set through the argument.

@Bassoonian restating for clarity

merge criteria is

1. Remove setmonball
2. Set VAR_RESULT to the number of removed items from removallitem
3. Remove checkspecies_auto and make its behavior the default, with the ability to use checkspecies_choose
4. still waiting on an answer to callnative discussion from above

@ghoulslash - was your feedback saying "convert the specials to callnative"?

All feedback addressed.